…AGENT_API_KEYS_DUAL_WRITE flag

Mirrors the AGX1-274 task dual-write pattern (PR #246) for agent_api_keys.

- Adds creator_user_id / creator_service_account_id / spark_authz_zedtoken
  columns to agent_api_keys, with CHECK constraint and concurrent indexes.
- On create, when FGAC_AGENT_API_KEYS_DUAL_WRITE is enabled for the caller's
  account, calls authorization_service.grant(AgentexResource.api_key(id))
  BEFORE the Postgres write. Grant failure aborts the create.
- On delete, best-effort revoke after the Postgres delete. Failures are
  logged but do not block the delete.
- Adds AgentexResourceType.api_key and AgentexResource.api_key(...) factory.
- Creates src/utils/feature_flags.py with both FGAC_TASKS_DUAL_WRITE and
  FGAC_AGENT_API_KEYS_DUAL_WRITE (file does not exist on main yet; if PR #246
  lands first this becomes a rebase concern).

Structural divergence from tasks: agent_api_keys have no service layer, so
the dual-write logic lives in AgentAPIKeysUseCase rather than a separate
service. This keeps the call site simple and avoids inventing a new layer.

Route layer (read-side auth checks) is out of scope; that's PR B (AGX1-273).
agentex-auth spark_mapping.py update is a sibling-repo concern.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…n creation

Adds two nullable creator-audit columns to the `tasks` table —
`creator_user_id` and `creator_service_account_id` — populated from
the request principal in `AgentTaskService.create_task`. A CHECK
constraint `ck_tasks_at_most_one_creator` enforces that at most one
of the two is set; partial indexes back future "tasks created by X"
lookups.

Online migration: the CHECK is added `NOT VALID` then
`VALIDATE`d separately so the brief ACCESS EXCLUSIVE lock doesn't
have to wait on an existence scan. `tasks` is a high-write table;
a vanilla CHECK addition would queue behind in-flight transactions
and block readers until released. Indexes use
`CREATE INDEX CONCURRENTLY` inside `autocommit_block`.

Best-effort attribution: tasks created outside an HTTP request
context (Temporal activities, background workers, any path that
constructs `AgentTaskService` without `request.state.principal_context`)
leave both columns NULL. The CHECK constraint allows both-NULL,
and an integration test exercises the no-resolvable-creator path.

These columns are how the AGX1-291 operator runbook identifies
orphan rows for backfill when the dual-write call sites added in
the next commit fail under load.

Part of the AGX1-264 stack: scaleapi/scaleapi NEW2
(per-account FF endpoint) → scaleapi/agentex#353 (agentex-auth
routing + cancel) → this PR → #249 (per-RPC
route migration). Two commits land together in #246; this one is
the schema/audit change and is independent of the dual-write call
sites.

Rewires the operation literal sent to agentex-auth on task RPC
routes so each RPC checks the permission that actually matches its
side effect, instead of using `execute` everywhere:

- `MESSAGE_SEND` / `EVENT_SEND` → `update`
- `TASK_CANCEL` → `cancel`
- `TASK_CREATE` stays `create`
- Unknown `AgentRPCMethod` values now raise `NotImplementedError`
  rather than falling through authz-free (defense-in-depth: a new
  RPC must be explicitly wired before it can dispatch).

The same `execute → update` swap is applied across `messages.py`,
`checkpoints.py`, and `states.py` so the editor role can perform
routine mutations without needing owner. The task SpiceDB schema
defines `permission update = (editor + owner) & internal_tenant_gate`,
so leaving these on `execute` (owner-only) would lock editors out
of normal flows.

Adds `check_task_or_collapse_to_404` in
`src/utils/task_authorization.py` and routes every task-resource
denial path through it: path id, query id, body id, and the name
surface in `authorization_shortcuts.py`. `tasks.name` is globally
unique, so a 403/404 split on the name route would let any
authenticated caller probe the whole system for task existence —
collapsing both denial cases into 404 closes that leak at the cost
of an in-tenant UX regression on permission-gap updates (tracked
under AGX1-290).

The `MESSAGE_SEND` task-name branch is restructured to
`try/else`: a denied update on an existing task must surface as 404
and NOT fall through to the create check, which would promote
"denied update" into create access.

Cross-repo wire dependency: the `update` and `cancel` literals
must resolve against the existing OWNER grant in SGP's task
permission schema before this deploys, otherwise every in-flight
agent's RPCs break at deploy time. Held behind that verification.

Part of the AGX1-264 stack: scaleapi/scaleapi NEW2
(per-account FF endpoint) → scaleapi/agentex#353 (agentex-auth
routing + cancel) → #246 (task FGAC
dual-write + audit columns) → this PR.

Rewires the operation literal sent to agentex-auth on task RPC
routes so each RPC checks the permission that actually matches its
side effect, instead of using `execute` everywhere:

- `MESSAGE_SEND` / `EVENT_SEND` -> `update`
- `TASK_CANCEL` -> `cancel`
- `TASK_CREATE` stays `create`
- Unknown `AgentRPCMethod` values now raise `NotImplementedError`
  rather than falling through authz-free (defense-in-depth: a new
  RPC must be explicitly wired before it can dispatch).

The same `execute -> update` swap is applied across `messages.py`,
`checkpoints.py`, and `states.py` so the editor role can perform
routine mutations without needing owner. The task SpiceDB schema
defines `permission update = (editor + owner) & internal_tenant_gate`,
so leaving these on `execute` (owner-only) would lock editors out
of normal flows.

Adds `check_task_or_collapse_to_404` in
`src/utils/task_authorization.py` and routes every task-resource
denial path through it: path id, query id, body id, and the name
surface in `authorization_shortcuts.py`. `tasks.name` is globally
unique, so a 403/404 split on the name route would let any
authenticated caller probe the whole system for task existence —
collapsing both denial cases into 404 closes that leak at the cost
of an in-tenant UX regression on permission-gap updates (tracked
under AGX1-290).

The `MESSAGE_SEND` task-name branch is restructured to
`try/else`: a denied update on an existing task must surface as 404
and NOT fall through to the create check, which would promote
"denied update" into create access.

Cross-repo wire dependency: the `update` and `cancel` literals
must resolve against the existing OWNER grant in SGP's task
permission schema before this deploys. `update` is already in
SGP's `AgentexOperation` enum; `cancel` is added by scaleapi/scaleapi
sgp-agentex-cancel-enum. Held behind that PR shipping everywhere.

Part of the AGX1-264 stack: scaleapi/scaleapi#145000
(FGAC_AGENTEX_AUTH_SPARK flag) -> scaleapi/scaleapi
sgp-agentex-cancel-enum (cancel enum on SGP backend) ->
scaleapi/agentex#353 (agentex-auth per-account routing + cancel) ->
#246 (task FGAC dual-write + audit columns)
-> this PR.